Use G38.3 in qt_auto_probe_tool.ngc to be able to check probe status.

[petterreinholdtsen]

There is a test after one of the G38.2 in question that look like this:

O500 IF [#5070 EQ 0]
G90
O500 return [-3] ; indicate probe contact failure to epilog
O500 endif

But the manual state that "If the probing operation failed, G38.2 and G38.4
will signal an error by posting an message on screen if the selected GUI
supports that. And by halting program execution.". When I try to include a similar
test in my test program, the program is aborted and the test is never executed.
This make me believe the wrong G code is used. Or is there something special
about the M6 remapping environment that make G38.2 behave differently?

Made sure both calls to G38.2 are changed to G38.2 with a test verifying the
status.

Also adjusted the handling of the measured height to take any coordinate system
offsets.

[c-morley]

These code changes seem good to me - have you tested the error process on a machine or sim?

[petterreinholdtsen]

[c-morley]

These code changes seem good to me - have you tested the error process on a machine or sim?

I could not get it to run in a simulator, and have not tested it on a machine. The setup in that directory did not work in the simulator with or without my change, and I did not understand what the problem was. -- Happy hacking Petter Reinholdtsen

[petterreinholdtsen]

[c-morley]

Need brackets around the addition:

Ah, of course. Thank you for noticing. Fixed.

…

-- Happy hacking Petter Reinholdtsen

[c-morley]

it seems there is also some needed changes in std_glue to get linuxcnc to notice the returned error numbers. Since it's a common library, I just don't know if it would break others relied on behavior.
Still checking that code change yet,

[petterreinholdtsen]

[c-morley]

it seems there is also some needed changes in std_glue to get linuxcnc to notice the returned error numbers. Since it's a common library, I just don't know if it would break others relied on behavior.

Which changes do you expect are needed? Are we talking about nc_files/remap_lib/python-stdglue/stdglue.py? It seem to only check return_value against 0. Note, I did not add a new return value (-3), I only added another place where the same return value was used. Similar code was already in place after the second G38.2.

Still checking that code change yet,

Great to hear you are giving it a critical view. :) Btw, Anyone know what the 'qt_' part of the qt_auto_probe_tool.ngc file name mean?

…

-- Happy hacking Petter Reinholdtsen

[c-morley]

QT because it was built for qtvcp's screens, though it should work for anyone.

[gmoccapy]

stuttgart meeting says @c-morley should decide on this.

[VectorHasting]

I'm happy to test this, I'm also working on pull request #2706, and @c-morley flagged this request there and asked if I could test. I've been delayed, and I apologize.

But I have questions:

It looks like from the comment at the beginning that the intention was to keep error codes... and I thought that was the difference between G38.2 and G38.3: that G38.2 returns an error code but G38.3 does not. The code has been changed to G38.3 at lines 69 and 79.

But the comment at the beginning seems to include an ambiguous typo:

Made sure both calls to G38.2 are changed to G38.2 with a test verifying the status.

Assuming what was meant is "change G38.2 to G38.3" I'm wondering if that will defeat getting an error message back??
Or, if the intention was to stop getting the error back, then why?

Those questions aside: how do I test this?

We are only talking about testing the QtDragon GUI, right? Or is this routine used in the other GUIs? (I've been using it on QtDragon)

My thought is to set up my machine so that the _ini[VERSA_TOOLSETTER]MAXPROBE is too small to get from the _ini[VERSA_TOOLSETTER]Z down to the probe surface. Then I would set myself up to issue a T2M6 command. That will call this remap code and I should get an error back to the GUI because it won't be able to get a probe signal while it's doing line 69 or line 79 (since the backoffdist will be heading up from the insufficiently low maxprobe).

Another thought: while I like very much the logical completeness of having the o600 section to check for the error after the reprobe... I nonetheless find myself wondering how that would actually every happen? There would have to be a probe failure of some kind between the success of line 69 and the start of line 79, otherwise 69 would have already failed. In fact, in order to test it, I think I would have to move the probe out of the way after the rapid probe and before the slow reprobe could get there. Hmmm. Not sure I want to try that, mine is bolted on an upright support.

Which, btw, brings me to: I have already gotten this error loads of times when my maxprobe distance is insufficient to reach the tool-setter. So, again I'm wondering if this switch to G38.3 is what is intended here, since it's been working for me without this change. On the other-hand, I'm hesitant about my knowledge here, so I'm very ready to be set straight, and thank you in advance.

Please advise :-)